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(57) A method for providing files to a remote node 
including the steps of determining whether 
bandwidth is available for transmitting across a 
communications link a file requested by a re- 
mote node, reserving bandwidth for the reques- 
ted file if bandwidth is determined to be 
available, and opening the requested file for 
transmission only if bandwidth is reserved. In 
addition, an apparatus for providing files to a 
remote node including apparatus for determin- 
ing whether bandwidth is available for transmit- 
ting across a communications link a file 
requested by a remote node, apparatus for 
reserving bandwidth for the requested file if 
bandwidth is determined to be available, and 
apparatus for opening the requested file for 
transmission only if bandwidth is reserved. 
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Related Patent Applications 

Related patent applications include commonly 
assigned copending patent application U.S. Serial 
No. 08/085.264 filed on the same date as the present 
application, entitled "SYSTEM AND METHOD FOR 
PROVIDING MULTIMEDIA QUALITY OF SERVICE 
SESSIONS IN A COMMUNICATIONS NETWORK" 
(IBM Docket No. AT9-93-060), hereby incorporated 
by reference; commonly assigned copending patent 
application U.S. Serial No. 

filed on the same date as the present application, en- 
titled "SYSTEM AND METHOD FOR BANDWIDTH 
RESERVATION FOR MULTIMEDIA TRAFFIC IN 
COMMUNICATIONS NETWORKS" (IBM Docket No. 
AT9-93-061), hereby incorporated by reference; and 
commonly assigned copending patent application 
U.S. Serial No. 08/085,275 filed on the same date as 
the present application, entitled "MULTIMEDIA RE- 
SOURCE RESERVATION SYSTEM" (IBM Docket 
No. AT9-93-063), hereby incorporated by reference. 

Technical Field 

The present invention relates to data processing 
systems and more particularly to data processing 
systems providing resource reservation to assure a 
desired quality of service. 

Background Art 

It has long been known to provide computer work- 
stations interconnected by digital communication net- 
works whereby users of the individual workstations 
may communicate with one another over the network 
for tasks such as file serving from a host or server to 
client computers. This has been previously common, 
for example, by means of a typed note, data or pro- 
gram file transmitted to another user. More recently, 
users have increasingly requested multimedia file 
services, desktop conferencing, remote presenta- 
tions, and other multimedia applications between 
network users. However, such multimedia applica- 
tions utilizing data-intensive sound, voice, and video 
flows require performance guarantees for high disk 
access and high bandwidth communication links be- 
tween distributed computing systems with minimal 
communication delay, maximum throughput, and in- 
stantaneous burst communication capability. As a re- 
sult it has become very difficult to schedule appro- 
priate resources to meet the requirements of such 
multimedia applications. 

Prior art has recognized that certain data in a net- 
work, such as that associated with multimedia, may 
require priority handling. Thus, for example, a "quality 
of service" (QOS) or bandwidth has been defined in 
the literature. Quality of service or bandwidth seeks 
to describe various parameters which may be speci- 
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f ied in an attempt to define certain minimum require- 
ments which must be met for transmission of given 
data types over the network. See, for example, qual- 
ity of service standards set forth in the OSI TP4 Open 
5 System Interconnect Standard X.214 and the quality 
of service standards defined in CCITTQ.931 (ISDN), 
Q.933 (frame relay), and Q.93B (B-ISDN ATM) drafts. 
As yet another example there is an architected priority 
mechanism in the IEEE 802.5 Token Ring. A station 

10 on the ring with a high priority frame to send may in- 
dicate this in an access control field of a passing 
frame. When a station sending the frame releases the 
token, it releases the token at the priority of the AC 
field, and eventually sets it back to its original priority 

is as specified in an IEEE 802.5 medium access control 
protocol. The IEEE standard and implementations 
thereof merely specify a protocol for increasing and 
decreasing priority. However, the user of such a ser- 
vice, such as a client-server file system, has to deter- 

20 mine when service guarantees are needed for certain 
file accesses. For example, multimedia file reads for 
playing sound, voice, and video from a server to a cli- 
ent need certain quality of service guarantees. 

Allocating resources when a connection is made 

25 between digital computers, such as for a client-server 
session, is known where memory is allocated to hold 
information related to the session. Buffers are also 
commonly reserved for file access on computers, 
such as on a server computer. Buffers may also be re- 

30 served on the client computer for multimedia file 
where a memory buffer must be large enough to store 
a reserve of file elements so that variations in delay 
between the server and client are absorbed. That is, 
there should be enough file elements stored in the 

35 memory buffer so that the buffer will not go empty 
during the playback of sound, voice or video. Other- 
wise, a glitch or jitter will occur causing a deteriation 
in the quality of a presentation. For example, if the 
maximum delay is two seconds and the multimedia 

40 flow averages 150 kilobytes per second, then a buffer 
at least 300 kilobytes in size is needed to preserve 
quality of service. 

Many types of files contain information in their 
header useful for determining such quality of service 

45 parameters. Other types of files may require that the 
file be read, parsed or scanned to determine such 
quality of service parameters. However, in a general 
purpose client-server environment, a very large vari- 
ety of file types and formats exist and a file server 

so may not be programmed to determine quality of ser- 
vice parameters in all cases. In addition, an applica- 
tion program, running on a workstation in a client-ser- 
ver environment, may not recognize whether a file be- 
ing accessed is located on the workstation or on a re- 

55 mote file server. If the file is located on the application 
program workstation, then quality of service is gener- 
ally met However, if the file being accessed is located 
on a remote server, then the file access must contend 

2 
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for server resources such as disk cycles or band- 
width, disk controller cycles, system bus resources, 
server processor resources, and network resources. 
As a -esult, it is difficult to maintain quality of service 
in a unent-server environment for remote file access- 5 
es. 

Summary of the Invention 

Provided is a method for providing files to a re- 10 
mote node including the steps of determining whether 
bandwidth is available for transmitting across a com- 
munications link a file requested by a remote node, 
reserving bandwidth for the requested file if band- 
width is determined to be available, and opening the 15 
requested file for transmission only if bandwidth is re- 
served. In a second aspect, the invention provides an 
apparatus for providing files to a remote node includ- 
ing means for determining whether bandwidth is 
available for transmitting across a communications 20 
link a fife requested by a remote node, means for re- 
serving bandwidth for the requested file if bandwidth 
is determined to be available, and means for opening 
the requested file for transmission only if bandwidth 
is reserved. 25 

A further understanding of the nature and advan- 
tages of the present invention may be realized by ref- 
erence to the remaining portions of the specification 
and the drawings in which: 

30 

Brief Description of the Drawing 

Fig. 1 is a block diagram of a typical data process- 
ing system utilized by a preferred embodiment of 
the invention; 35 
Fig. 2 is an illustration of a data processing sys- 
tem including three workstations interconnected 
by a network in accordance with the subject in- 
vention; 

Fig. 3 is a block diagram illustrating a multi- 40 
layered computer communication network model 
based upon the OSI layered reference model; 
Fig. 4 is a block diagram of a preferred layered 
open systems interconnection model showing the 
relationship of components of the subject inven- 45 
tion to the layers; 

Fig. 5 is a flowchart illustrating initializing a host 
system with default quality of service parameters 
for types of files; 

Fig. 6 illustrates a default table generated by the so 
process described in Fig. 5; 
Figs. 7A-7C are a flowchart illustrating a prefer- 
red method for individually determining quality of 
service parameters for files; 

Fig. 8 is a block diagram of a reservation table 55 
utilized by the resource reservation system to 
handle resource reservations according to a pre- 
ferred embodiment of the invention; and 



Figs. 9A-9B are a flowchart illustrating a prefer- 
red method for reserving a desired quality of ser- 
vice of various resources. 

Specific Description 

Fig. 1 is a block diagram of a typical data process- 
ing system 100 utilized by a preferred embodiment of 
the invention. The data processing system includes 
main processor(s) 110 coupled to a main memory 1 20 
in computer box 1 05 with input device(s) 1 30 and out- 
put device(s) 140 attached. Main processors) 110 
may include a single processor or multiple proces- 
sors. Input device(s) 130 may include a keyboard, 
mouse, tablet or other types of input devices. Output 
device(s) 140 may include a text monitor, plotter or 
other types of output devices. 

The main processor may also be coupled to 
graphics output device(s) 210 such as a graphics dis- 
play through a graphics adapter 200. Graphics adap- 
ter 200 may be located in an adapter slot 160A. 
Graphics adapter 200 receives instructions regarding 
graphics from main processor 110 on bus 1 50, there- 
by rendering the desired graphics output from the 
main processor. 

A communications adapter 250 such as a modem 
or a network adapter for networks such as token ring 
or ethernet may be located in slot 160C. The slot pro- 
vides communications with main processor 110 
across bus 150. Communications adapter 250 may 
communicate with other data processing systems 270 
across communications line 260. As a result, the main 
processor may communicate with other data process- 
ing systems 270 via bus 150, slot 160C, communica- 
tions adapter 250 and communications line 260. 

A hard disk 255 may be located in slot 160D to 
provide additional memory for use by the main proc- 
essor. Computer readable removable media 290, 
such as a magnetic diskette or a compact disc, may 
be inserted into an input/output device 285, such as 
a disk drive or a CD-ROM (compact disc - read only 
memory) drive. Data is read from or written to the re- 
movable media by the I/O device under the control of 
the I/O device controller 280. The I/O device control- 
ler communicates with the main processor through 
slot 160E across bus 150. Main memory 120, hard 
disk 255 and removable media 290 are all referred to 
as memory for storing data for processing by proces- 
sor 110. One of the preferred implementations of the 
present invention is as several sets of instructions in 
a code module resident in the main memory 1 20. Until 
required by the computer system, the sets of instruc- 
tions may be stored in another computer memory, for 
example, in a hard disk drive, or in a removable mem- 
ory such as an optical disk or floppy disk for eventual 
use in a CDROM or the floppy disk drive. 

Fig. 2 illustrates a data processing system com- 
prising a number of workstations (here, three work- 



BNSDOCID:<EP 0632671 A2> 



G 



5 EP 0 632 671 A2 6 



stations 300, 320, and 330) interconnected by a pair 
of data networks 310 and 340 (also referred to as 
communications links), so as to permit communica- 
tion between the workstations (also referred to as 
nodes). It is assumed that the data processing shown 5 
in Fig. 2 is of a type which permits concurrent real- 
time communication between the users. The network 
operates according to a conventional network proto- 
col, such as the token ring protocol described in Token 
Ring Network Architecture reference, SC30-3374, 10 
IBM, 1989. 

Fig. 2 depicts only one possible hardware config- 
uration for a data processing network. Other config- 
urations are possible. For example, the data process- 
ing system could be based upon a star network, or a 15 
host processor connected to a plurality of dumb ter- 
minals, or could further be based upon a plurality of 
remote processors connected by a communication 
network, the networks could also be based upon the 
telephone network, and ISDN network, or any other 20 
"dial up" networks. Moreover, the workstations could 
be located within the single workspace or within a lo- 
cal area, or could be remote from one another. A 
source for detailing technical planning information for 
configuring a network of workstations in accordance 25 
with the invention, is the IBM Extended Services for 
OS/2 Example Scenarios Manual , 1991. 

Multimedia computing is the processing of vari- 
ous media, such as video, waveform audio, musical 
instrument digital interface (MIDI) streams, anima- 30 
tion, graphics, and text. Media processing includes 
the capture, authoring (editing) and playback of me- 
dia streams as well as other data processing applica- 
tions. Multimedia documents which are stored on 
some non-volatile medium, such as a disk, are refer- 35 
red to as recorded multimedia applications. There are 
also live multimedia applications in which two or more 
people communicate with each other at the same 
time using a computer. Live multimedia applications 
are normally conducted across space and time indi- 40 
eating that live multimedia is inherently distributed. 
Even recorded multimedia applications require dis- 
tributed file system services to share large volumes 
of stored media, such as video disk, audio informa- 
tion, or computer-generated images. Thus, it is critical 45 
that a prioritizing scheme in accordance with the in- 
vention for multimedia applications includes support 
for a distributed environment. 

To reduce design complexity, most networks are 
organized as a series of layers, each one built upon so 
its predecessor as described in Computer Networks , 
Tannenbaum, Andrew S., Prentice Hall (1988) and 
OSl, A Model for Computer Communications Stan- 
dards , Black, Ulyess, Prentice Hall, 1991. The num- 
ber of layers, the name of each layer, contents, and 55 
function of each layer differ from network to network. 
However, in each network, the purpose of the layers 
is to offer certain services to the higher layers, shield- 



ing those layers from the details of how the offered 
services are actually implemented. The purpose, 
function, and details of each of the layers and their in- 
teraction is set forth in the previously noted referenc- 
es and is familiar to communication programmers or- 
dinarily skilled in the art. 

Priority assurance is an important factor in ensur- 
ing bandwidth or quality of service, and is enabled by 
operation of a component which may be implemented 
in hardware logic or software. The component regu- 
lates access to the priority queue or transmit that is 
attached to the shared medium local area network 
section. Access to the priority queue or transmit chan- 
nel will pass through this component, thus subjecting 
all communication transactions to rejection or track- 
ing by the component. A more detailed discussion of 
this component and the related station's bandwidth 
manager component are described in commonly as- 
signed copending patent application U.S. Serial No. 
07/930,587, filed August 17, 1992, entitled "Network 
Priority Management" (IBM Docket No. AT9-92-089), 
hereby incorporated by reference. 

Fig. 3 is a block diagram illustrating a multi- 
layered computer communication network model 
based upon the OSl layered reference model. Further 
detail of this OSl and related IEEE models may be 
found in OSl, A Model for Computer Communications 
Standards , infra. A client system 20A is shown com- 
municating with a server system 20B across a com- 
munications link 30. The seven layers of the OSl mod- 
el for each system are shown as reference numerals 
40-52. The lowest layer is physical layer 40A-40B 
which is responsible for implementing a physical cir- 
cuit between data terminal equipment and data circuit 
terminating equipment. 

A data link layer 42A-42B is responsible for trans- 
fer of data across the link. A network layer 44A-44B 
specifies the interface of the user into a network and 
also defines network switching/routing and communi- 
cations between networks. Atransport layer 46A-46B 
provides an interface between the data communica- 
tions network and the upper three layers. This layer 
is of particular interest because it provides the user 
options in obtaining certain levels of quality, and is de- 
signed to keep the user isolated from some of the 
physical and functional aspects of the network. A ses- 
sion layer 48A-48B serves as a user interface into the 
transport layer below, providing a means for ex- 
change of data between users such as simultaneous 
transmission, alternate transmission, checkpoint pro- 
cedures and the like. The remaining two layers, a pre- 
sentation layer 50A-50B and an application layer 
52A-52B ensure that user applications can communi- 
cate with each other and further concern the support 
of the end-user application process. Please note that 
each of the client system layers is shown communi- 
cating with the corresponding server system layers. 
Although each of the layers perceives that these com- 
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munications are direct, the communications are 
shown as dotted lines because to the only direct com- 
munications are performed through the network. 

It will be noted from Fig. 3 that there are other im- 
plementations in the art of such an OSI reference 5 
model bearing varying degrees of similarity thereto, 
a portion of one being depicted in the left part of Fig. 
3 as the IEEE model, a physical layer 60 may be seen 
corresponding to the physical layer of the OSI model. 
The IEEE recognized a need to divide the data link w 
layer into two sublayers in order to handle different 
link configurations and thus a medium access control 
(MAC) 62 and logical link control (LLC) 64 were pro- 
vided for. The sublayer is protocol-specific (such as 
to a LAN such as Ethernet) whereas as the LLC 15 
serves as an interface to an upper layer protocol, typ- 
ically the network layer (and isolates the network lay- 
er from the specific actions of the MAC sublayer). 
One purpose of depicting varying forms of a multi- 
layered computer communication network in Fig. 3 is 20 
to illustrate that the invention admits to implementa- 
tions in any number of such multilayered models, and 
is thereby not intended to be limited to application to 
the OSI reference model emphasized in the descrip- 
tion herein. 25 

Fig. 4 is a block diagram of a preferred layered 
open systems interconnection model showing the re- 
lationship of components of the subject invention to 
the layers and to the data processing system. An ap- 
plication program 70 on a client system seeks a file 30 
to be accessed through a file system application pro- 
gram interface (API) 72 to a redirector 74. If the file 
is not located on the client system, then the redirector 
determines which remote system, such as the server 
system, has the desired file. If the file is located on 35 
the client system, then the file is accessed on a local 
file system not shown. If the file is located on the ser- 
ver system, then the redirector passes a request for 
access to the desired file to the server system 
through a communications transport 76 (such as net- 40 
bios or TCP/IP) to a network adapter device driver 78. 
The network device driver then sends the request to 
the server system through a network adapter 79 
across a communications link 80 (such as ethernet or 
token ring) to the server system network adapter 99 45 
and network adapter device driver 98. The network 
adapter device driver then passes the request on to 
the communications transport 96. The communica- 
tions transport then passes the request on to a high 
performance file system (HPFS) 94. The high perfor- 50 
mance file system then passes the file request onto 
a resource reservation system (RRS) 92. The re- 
source reservation system then determines whether 
there are any quality of service parameters for the re- 
quested file. If not, then the resource reservation sys- 55 
tern so notifies the high performance file system. The 
high performance file system then accesses the file 
on a local disk drive not shown. If the resource reser- 



vation system determines trr-t there are quality of 
service parameters for the requested file, then the re- 
source reservation system then automatically re- 
serves the appropriate resources to ensure that the 
quality of service for the file is maintained. This proc- 
ess will be described in detail below. The resource 
reservation system so notifies the high performance 
file system. The high performance file system then 
opens and accesses the file through a local file sys- 
tem to a local disk drive. Access to the file is then pro- 
vided to the requesting application program, with 
quality of service guarantees if established, and the 
application program is so notified. This notification 
occurs through communications transport 96, net- 
work device driver 98, network adapter 99, commu- 
nications link 80, network adapter 79, network device 
driver 78, communications transport 76, redirector 
74, and file system API 72. Please note that the ele- 
ments of the client and server systems are shown cor- 
responding to layers of the OSI model described 
above. In addition, the elements of the client and host 
systems correspond to the elements of the data 
processing system described above. Elements 70-78 
reside in memory of the client system and are execut- 
ed by the client system processor. Network adapters 
79 and 99 are communications adapters for the client 
and hosts systems respectively. In addition, portions 
of the network adapter device drivers may reside on 
and be executed by the network adapters. Commu- 
nications link 80 may be a network such as Ethernet 
or Token ring. Elements 92-98 reside in memory of 
the host system and are executed by the host system 
processor. 

This system allows for easy access to the files 
across a network and also provides the capabilities 
for an automatic resource reservation system as will 
be described below. 

Determining Quality of Service Parameters 

There are many types of quality of service para- 
meters known in the art The parameters of particular 
interest to a preferred embodiment of the invention 
are throughput, burst, and delay. Throughput is the 
average amount of information passed through the 
communications link in a given period of time such as 
150 kilobytes per second. Burst is the maximum 
amount of information passed through the communi- 
cations link in a short period of time. Delay is the max- 
imum amount of delay that can be tolerated, typically 
due to buffer size in relation to throughput. 

Default quality of service parameters may be pro- 
vided for files for types of files. That is, files are typ- 
ically stored as XXXXXX.YYY where .YYY is the ex- 
tension of the file. The extension typically describes 
the what type the file is (e.g. .VOC for a voice file 
and .WAV for a wave file). These default values may 
be provided 
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Fig. 5 is a flowchart illustrating initializing a host 
system with default quality of service parameters for 
types of files. In step 350, the user provides to the 
high performance file system (HPFS) a quality of ser- 
vice (QOS) file listing file types and quality of service 5 
parameters for each file type. The user may provide 
this QOS file in a variety of ways. A soft copy of a QOS 
file may be provided with a set of multimedia files by 
a vendor and provided therewith for installation by the 
user or the vendor may provide a software tool for the 1 o 
user to use to create the QOS file. In addition, the 
user may respond to a set of queries from the host 
system. In step 360, the first entry in the QOS file is 
read. In step 370, if end of file is not reached, then 
processing continues to step 380. In step 380, a de- 15 
scription of the file type and its quality of service 
parameters are extracted from the record and added 
to a default table in memory. Fig. 6 illustrates a default 
table 392 generated by the process described in Fig. 
5. The default table may include values for file type 20 
393, throughput 394, burst 395, and delay 396. Proc- 
essing then returns to step 360 to read the next record 
in the QOS file. If end of file is reached in step 370, 
then the default table containing the file types and 
quality of service parameters are provided to the re- 25 
source reservation system (RRS) for later use as will 
be described below. 

Figs. 7A-7C are a flowchart illustrating a prefer- 
red method for individually determining quality of ser- 
vice parameters for files. There are many types of 30 
files which may require quality of service and it is pre- 
ferable to obtain the quality of service parameters for 
an individual file when that file is transferred to the 
host computer for storage on the host computer. This 
individual determination of quality of service parame- 35 
ters for files may be performed automatically for cer- 
tain types of files such as voice (VOC), wave (WAV), 
audio-visual (AVI), or other types of multimedia files. 
These quality of service parameters may also be ob- 
tained by querying the operator as the files are trans- 40 
ferred stored in the host computer. In an alternative 
embodiment, the quality of service parameters may 
be determined when a file is first used or at each use 
of a file. In another alternative embodiment, the qual- 
ity of service parameters may be determined for an 45 
application by accumulating the quality of service 
parameters of each file to be accessed by the appli- 
cation. 

In step 400, the file is transferred to the host com- 
puter for storage. The host computer may receive the so 
file from an external media such as a CD-ROM or 
floppy disk, or from another data processing system 
across a communications adapter. In step 405, it is 
determined whether quality of service parameters are 
to be calculated for the transferred file. The user may 55 
request calculation of quality of service parameters 
by using a particular command to transfer the file to 
the host system. In addition, the host system may au- 



tomatically calculate quality of service parameters for 
certain types of files. If no parameters are to be cal- 
culated, then processing ends. Otherwise, in step 
410, a quality of service calculation utility may be 
executed to determine the quality of service parame- 
ters for the file. This utility may be executed at the re- 
quest of the user storing the file on the host system 
or the utility may be automatically executed for cer- 
tain types of predesignated files. In step 420 the ex- 
tension of the file is obtained. That is, files are typi- 
cally stored as XXXXXX.YYY where ,YYY is the ex- 
tension of the file. The extension typically describes 
the what type the file is (e.g. .VOC for a voice file 
and .WAV for a wave file). Multimedia files are prefer- 
ably distinguished into two types, fixed sample or va- 
riable sample. Fixed sample files have fixed length 
sample records and may include a header record de- 
scribing the records. An example of a fixed sample 
file is a voice (VOC) file which typically has a header 
followed by a number of contiguous bytes, each byte 
being an eight sample. The header provides informa- 
tion about the sampling rate (e.g. 8000, 11000 or 
44000 samples per second) and the number of chan- 
nels (e.g. one for mono, two for stereo, more than two 
for multichannel). Variable sample files have variable 
length sample records and require greater processing 
to determine quality of service parameters according 
to the preferred embodiment of the invention. An ex- 
ample of a variable sample file is a digital video inter- 
active (DVI) file which has a series of reference 
frames with two or more delta frames interspersed 
between each pair of reference frames. The size of 
the delta frames depends on the amount of move- 
ment occurring between reference frames. In step 
430, based on the extension, if the file is a fixed sam- 
ple file then processing continues to the flowchart of 
Fig. 7B. If the file is a variable sample file, then proc- 
essing continues to the flowchart of Fig. 7C. 

Once the quality of service parameters are ob- 
tained, then in step 440, the quality of service para- 
meters are preferably stored as extended attributes 
of the file. That is, many operating systems such as 
OS/2 (trademark of International Business Machines 
Corp.) have the capability of storing and retrieving ex- 
tended attributes for any file without requiring the file 
be opened. Extended attributes are described in de- 
tail in the OS/2 2.0 Technical Library, Programming 
Guide , Volume 1, Version 2.00, hereby incorporated 
by reference. As result, the extended attributes may 
be accessed to determine whether appropriate re- 
sources are available for utilizing the file prior to 
opening the file. In alternative embodiments, the 
quality of service parameters may be stored in the file 
or may be stored in a table with reference to the file. 
If the quality of service parameters are determined 
each time the file is used, then the parameters do not 
need to be stored. 

Fig. 7B is a flowchart illustrating a preferred 
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method for determining quality of service parameters 
for fixed sample files (that is, files that have fixed 
length records for each sample and typically have a 
header record describing the records). In step 500, 
the file header is read. If a file header is not available, 5 
then the first record in the file is read. In step 510, in- 
formation for determining quality of service is extract- 
ed from the file header or the first record. For fixed 
sample records, the number of concurrent channels 
or data streams, the frequency of sampling data, and w 
the sample size are extracted from the file. 

In step 520, the quality of service parameters are 
calculated from the information obtained from the 
file. These parameters are determined for reading the 
files. However, the parameters could also be deter- is 
mined for writing to the files. The quality of service 
parameters typically determined are read throughput 
and read burst. Throughput is the average number of 
bits or bytes needed to transmit per second in order 
to provide realtime use of the data. Factors includes 20 
the number of channels (mono, stereo or multichan- 
nel), the sampling frequency, and the sample size. 
For example, the throughput would be equal to the 
number of data streams times the sample frequency 
times the sample size. That is, a stereo signal with a 25 
sample rate of 44 kilohertz with a sample size of 16 
bits per sample may be utilized for compact disk qual- 
ity music file for a throughput of 1 76 kilobytes per sec- 
ond. In addition, other QOS parameters such as 
burst, minimum data throughput, maximum data 30 
throughput, or other measures may be calculated. 
Burst is the amount of data typically transmitted in a 
short time interval. Other possible parameters could 
be determined including various measures of disper- 
sion for variable sample files. For example, a through- 35 
put average and a throughput standard deviation 
could be determined. These parameters are deter- 
mined by determining the amount of data to be trans- 
mitted. Processing then returns to Fig. 7A where the 
parameters are then stores as extended attributes of 40 
the file. 

Fig. 7C is a flowchart illustrating a preferred 
method for determining quality of service parameters 
for variable sample files (that is, files that have fixed 
length records for each sample and typically have a 45 
header record describing the records). 

In step 600, the file header and file trailer are 
read if available. In step 610, the number of frames 
in the file of video is determined from information in 
the header or trailer. In step 620. the frame rate is also so 
determined based on information in the header or 
trailer of the file. For example, NTSC (National Tele- 
vision Standard Committee) signals are 29.97 frames 
per second and PAL television signals are 25 frames 
per second. In step 630 the first frame of the file is 55 
read. In step 640 the number of bytes in the frame is 
calculated and stored. In step 650 it is determined 
whether this is the last frame in the file. If no, then 
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processing returns to step 630 to read the next frame 
and extract information from that frame. If yes, then 
in step 660. the various quality of service parameters 
are calculated including throughput and burst. Proc- 
essing then returns to Fig. 7A where in step 450, the 
quality of service parameters are then stored as ex- 
tended attribute of the file. 

Determining Network Capacity 

Before reservation of resource capacity is per- 
formed, it is preferable that the amount of that capaci- 
ty be determined for the various types of networks 
and other resources that may be reserved. Resource 
capacity may easily be obtained by querying the op- 
erator of the system. However, the operator may not 
know the capacity or the capacity may vary since the 
operator was queried. For example, a network may be 
slowed by more clients being added to the network, 
thereby increasing network overhead. Resource ca- 
pacity may also be determined by determining what 
resources are available. For example, the host sys- 
tem may detect what resources are on the system 
during initial program load (sometimes referred to as 
sniffing). The host system may then compare the re- 
sources detected to a table listing capacities for all 
types of resources to determine what the resource ca- 
pacity is. Resource capacity may also be determined 
by running some benchmarking tools to detect what 
the actual capacity of the resources are. For exam- 
ple, a series of reads and writes to a disk drive to de- 
termine its capacities. 

Reserving Quality of Service 

Fig. 8 is a block diagram of a reservation table 
800 utilized by the resource reservation system to 
handle resource reservations according to a prefer- 
red embodiment of the invention. The reservation ta- 
ble includes a listing of each resource 81 0, its location 
820, and its capacities 830 that are available for res- 
ervation. The reservation table also includes a vari- 
able number of reservations 840 for each resource. 
For example, an ethernet adapter located in adapter 
slot #1 has a capacity of 2 megabytes per second and 
has two reservations of that capacity. 

Figs. 9A-9B are a flowchart illustrating a prefer- 
red method for reserving a desired quality of service 
of various resources. This reservation process is pre- 
ferably performed for desired files, typically multime- 
dia or other types of files requiring uninterrupted ser- 
vice, as those files are opened. However, the below 
described process may also be utilized for providing 
quality of service for desired sessions or applications. 
The below processing steps typically occur when a re- 
quest is received by the host system from an applica- 
tion program to open a file for transmission across the 
network. This request may be in the form of a read, 
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write or other type of command. Typically, the appli- 
cation program making the request is located on a cli- 
ent system on the network and will be needing the 
contents of the file for use by the application program. 

In step 900, the request is received from an ap- 5 
plication program to open a file on the host system for 
use across the network. The file may be a type of file 
that needs a reservation to preserve quality of ser- 
vice or the application program may request that a 
reservation be made for the file. In the preferred em- 10 
bodiment, the high performance file system (HPFS) 
identifies a file needing reservation by matching the 
extension of the file against a list of file extensions 
provided by the resource reservation system (RRS). 
In step 910 the HPFS determines whether the file has 15 
any extended attributes. If not, then processing con- 
tinues to step 915. If extended attributes for the file 
do exist, then in step 930 the HPFS reads extended 
attributes into memory. In step 940 the HPFS deter- 
mines whether quality of service (QOS) parameters 20 
are found in the extended attributes. If not, then proc- 
essing returns to step 915. : iep 915, the RRS de- 
termines whether any defau, . parameters exist for the 
requested file. If so, then the quality of service para- 
meters are read from the default table. If default para- 25 
meters do not exist, then there are no quality of ser- 
vice parameters for the file and a normal file open is 
performed. In an alternative embodiment the host 
system may then determine quality of service para- 
meters of the file at this time, possibly at the request 30 
of the client system. In this alternative embodiment, 
processing would then continue to step 950 below. 

If quality of service parameters are found or de- 
termined in either extended attributes of the file or in 
the default table, then processing continues to mak- 35 
ing a reservation for the file by utilizing the resource 
reservation system. In step 950 a reservation is made 
on disk to meet the quality of service needs for the 
file. For example, a video stream may require 150 
kilobytes per second while a disk may have 1.8 meg- 40 
abytes per second bandwidth. In this step the reser- 
vation to the disk for 150 kilobytes per second is 
made. In step 955, if the disk reservation is not suc- 
cessful then the open is failed and processing contin- 
ues to step 925. In step 925, an error signal is re- 45 
turned to the application program originating the file 
request. The application program may then request 
the file be opened without a reservation. In an alter- 
native embodiment, the command received from the 
remote system may include an instruction to open the so 
file even if quality of service is not reserved. In this 
alternative embodiment, processing would continue 
to step 920 for opening the file. If the disk reservation 
is successful, then in step 960 a bus reservation is 
made to meet quality of service needs for the file. For 55 
example, one would reserve 150 kilobytes per sec- 
ond for a video stream for the bus. In step 965, if the 
bus reservation is unsuccessful, then processing re- 



turns to step 925 for generating an error signal to the 
application program. If a bus reservation is success- 
ful, then in step 970 main memory is reserved to meet 
quality of service needs for the file. For example, one 
may need to reserve 64 kilobytes per second of mem- 
ory for the read buffer to satisfy a video system read. 
In step 975 it is determined whether the memory res- 
ervation is a success. If not, then processing returns 
to 925. Otherwise, processing continues to step 980 
where a network reservation is made to meet quality 
of service needs for the file. For example, a video 
stream may need 1.2 megabyte per second reserva- 
tion on the network. In step 985, if the network res- 
ervation is a success, then processing returns to step 
925 to generate an error signal to the application pro- 
gram. Otherwise, in step 990, the file is opened and 
a success signal is returned to the requesting appli- 
cation program indicating that the file is available with 
reserved quality of service. 

One main advantage of the present invention is 
that a file may not be opened for transmission until a 
reservation is made. Opening a file for transmission 
is an operation requiring a large amount of overhead 
for the host system. That is, in typical data processing 
systems, a file directory in the host needs to be read 
and control structures enabling access to the file 
need to be set up. This overhead is particularly cum- 
bersome when the host system is already heavily 
loaded or overloaded with many demands on its sys- 
tem resources. As a result, the present invention 
helps relieve that burden by not requiring a file open- 
ing when resources are not available. 

Although the present invention has been fully de- 
scribed above with reference to specific embodi- 
ments, other alternative embodiments will be appa- 
rent to those of ordinary skill in the art. 



Claims 

1. A method for providing files to a remote node of 
a communications network, comprising the steps 
of: 

determining whether bandwidth is avail- 
able for transmitting across a communications 
link a file requested by a remote node; 

reserving bandwidth for the requested file 
if bandwidth is determined to be available; and 

opening the requested file for transmis- 
sion only if bandwidth is reserved. 

2. A method according to Claim 1 , further compris- 
ing a step of notifying the remote node when 
bandwidth is determined not to be available for 
transmitting the requested file. 

3. A method according to claim 1 or claim 2, further 
comprising a step of determining bandwidth re- 
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quirements for transmitting the fi!e. 

4. A method according to claim 3 wherein the step 
of determining includes determining bandwidth 
requirements for the file is carried out when the 5 
file is initially received by the current node. 

5. A method according to claim 3 or claim 4 wherein 
file attributes, which are managed separately 
from the data content of the file, are used to de- w 
termine bandwidth requirements. 

6. An apparatus for providing files to a remote node 
of a communications network, comprising: 

means for determining whether bandwidth 
is available for transmitting across a communica- 
tions link a file requested by a remote node; 

means for reserving bandwidth for the re- 
quested file if bandwidth is determined to be 
available; and 

means for opening the requested file for 
transmission only if bandwidth is reserved. 

7. Apparatus according to claim 6, further compris- 
ing means for notifying the remote node when 25 
bandwidth is determined not to be available for 
transmitting the file. 

8. Apparatus according to claim 6 or claim 7, further 
comprising means for determining bandwidth re- 30 
quirements for transmitting the file. 

9. Apparatus according to any one of claims 6 to 8 t 
including: 

storage means for storing files to be proc- 
essed and transmitted; 

processing means for processing said 
stored files; and 

means for determining bandwidth require- 
ments for the file when the file is initially received 
for storage on said storage means. 
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